Support concurrent use of a shared JavaVirtualMachine
#69
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Instead of having the JavaVirtualMachine instance keep track of the JNI environment for the thread in which it was initialized, provide a JNI environment query function that attaches the current thread to the JVM if needed. This lets us query the JNI environment for multiple threads, should we want to. We no longer need to force all of the JavaKit runtime tests to the main actor.
Java implementations have a longstanding limitation that there may only be one Java Virtual Machine instance per process. Take advantage of this to provide a shared JavaVirtualMachine instance, initialized on first use, that can be accessed from any thread. This eliminates the need to force JavaVirtualMachine creation to be on the main actor, since we can do it from any thread and get the same result.
This also cleans up various error-handling code paths that were doing narrow checks.
Member
Author
|
Merging because I'm building other things on top of this |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
JavaVirtualMachineclass was not at all designed with concurrency in mind: it always created a new Java VM under the hood, and was associated with a single JNI environment even though different threads could have different JNI environments.Move to a different model with a
static shared()method to create or access a sharedJavaVirtualMachineinstance to encapsulate the (singleton) JVM. If there is an existing JVM, whether created via this Swift library or from some other code, it will be adopted by the sharedJavaVirtualMachineinstance.Additionally, the
JavaVirtualMachineno longer stores a JNI environment. Instead, it now provides anenvironmentfunction that queries the JVM to get the JNI environment for the current thread. If the current thread isn't attached to the JVM, it does so and provides the resulting JNI environment.With all of these in place, we no longer need to force all of our JavaKit tests over to the main actor.